Network fault system

ABSTRACT

The fault system includes an interface for accessing first data fault representative of faults in the reported by users of mobile stations of the network, an interface for accessing second fault, data representative of faults in the network determined by a network analysis system, and pattern matching device for allocating the first and second fault data to fault patterns, representative of faults having at least one common characteristic. The common characteristics is geographic location and fault type. The fault system further includes pattern generation device for generating the fault pattern using respective fault templates to allocate the fault data to the fault patterns.

The present invention relates to a network fault system for a mobiletelecommunications network, and to a fault pattern matching process.

Telecommunications networks include switching equipment which is able toprovide extensive data on the state of performance of the equipment andother aspects of the network. However in a network which is not fixedand is subject to a variety of operating conditions, such as a mobiletelecommunications network, the data provided by the equipment can onlyprovide information on the network to the extent that operatingconditions are known. For a mobile network, it is presently impossibleto determine from the network equipment the precise location, and hencethe operating conditions, for a mobile station. Therefore it isdifficult to determine whether faults reported by users or customers ofthe network are due to a fault in the network or not. It would beadvantageous to have a system which can use network fault data andinformation provided by users of a mobile network to form groups ofrelated fault data that could be used to corroborate faults.

In accordance with the present invention there is provided a networkfault system for a mobile telecommunications network including:

a first interface for accessing first fault data representative offaults reported by users of mobile stations of said network;

a second interface for accessing second fault data representative offaults in said network determined by a network analysis system; and

pattern matching means for allocating said first and second fault datato fault patterns representative of faults having at least one commoncharacteristic.

The present invention also provides a fault pattern matching processincluding:

accessing first fault data representative of faults reported by users ofmobile stations of a mobile telecommunications network;

accessing second fault data representative of faults in said networkdetermined by a network analysis system; and

allocating said first and second fault data to fault patternsrepresentative of faults having at least one common characteristic.

A preferred embodiment of the present invention is hereinafterdescribed, by way of example only, with reference to the accompanyingdrawings, wherein:

FIG. 1 is a block and flow diagram of a preferred embodiment of anetwork fault system; and

FIG. 2 is a flow diagram of a procedure of an Automatic Pattern Matcherof the network fault system.

The network fault system 2, as shown in FIG. 1, is able to identifypatterns in faults reported by customers or users of a mobiletelecommunications network, manage the creation and execution of aprocess for resolving fault patterns, and control the provision of faultpattern information to personnel supporting customers. The system 2stores all fault and pattern data in an Oracle ™ database 4. Data onfaults reported by the customers is held in customer fault databases 6and the system 2 includes an interface 8 for providing the customerfault data to the database 4 from the customer fault databases 6.Network fault data is reported by a network analysis system 10, of thetype described in the applicant's co-pending International PatentApplication No. PCT/AU96/00511, and the system 2 includes a network dataentry interface 12 which allows the reported network fault data to beaccessed and passed to the fault and pattern database 4 via a patternidentification and distribution module 14 of the system 2. The module 14includes a number of interfaces 16, 18, 20 and 22 for controllingprocessing of the data held in the fault and pattern database 4.

The network fault system 2 also includes a pattern matcher module 24which comprises a template module 26 for defining pattern templates andan automatic pattern matcher engine (APM) 28 for forming fault patternsfrom the customer and network fault data based on the pattern templates.

Data held on the fault and pattern database 4 is accessible by acustomer service module 30 which includes a consultant user interface 32and a customer support user interface 34.

The network fault system 2 operates on a computer workstation, such as aSun Microsystems Sparc Station 5 running Unix, and the interfaces 8 and12, and the modules 14 and 24 are implemented by software written inC++. The customer service module 30 is also implemented in softwarerunning on personal computers used by customer service representatives(CSRs). Although a software implementation is described herein, thesystem 2 could also be implemented using a combination of applicationspecific integrated circuits and firmware.

A help desk system 40 comprises a CSRs PC, the customer service module30 and other customer support software stored on the PC, and is used torecord details of a CSRs interaction with a customer when a customerreports a problem experienced using the customer's mobile station orhandset. The help desk system 40 includes an inference engine whichdetermines whether the reported problem is associated with thecustomer's mobile station or with the mobile telecommunications network.In either case, the help desk system 40 stores details of the customer'sproblem in one of the customer fault databases 6. Problems determined bythe help desk system 40 to be network faults are placed into a specificqueue in the customer fault databases 6 from which the system 2 canaccess the customer fault data using an interface 8. The customer faultdata accessed by the interface 8 and stored in the fault and patterndatabase 4 includes the following fields for each record:

Field 1: Fault number

Field 2: Customer account name

Field 3: Customer address

Field 4: Mobile phone number

Field 5: Data and time the customer reported the problem

Field 6: Location of the fault: street, suburb, city, intersectingstreet

Field 7: Pattern number allocated to fault

Field 8: A maximum of two symptoms observed by the customer (a symptomis recorded as a code)

The network analysis system 10 is able to supply the fault system 2 witha list of faults which have occurred in network components or entities.The fields included in each record of the network fault data are asfollows:

Field 1: Network entity type (cell or exchange, analogue or digitalnetwork)

Field 2: Network entity name (the name of the cell or exchange)

Field 4: Fault creation time stamp

Field 5: Fault name (recorded as a fault code)

Field 6: Confidence measure in fault (value between 0.0 and 1.0)

Field 7: List of symptoms supporting the fault (evidence)

Examples of fault names for cells of a mobile cellular network include:

Faulty Rx antenna

Fault in Rx path at base station

Misdirected Rx antenna

Misdirected Tx antenna

Examples of fault names for exchanges include:

Unable to handle offered traffic

Massive paging fault

Multi access across switch boundary

Switch problem

Examples of cell fault symptoms include:

Calls in progress dropouts>5%

Failed handoffs in>5%

The network fault data is accessed using the network data entryinterface 12 and then finally entered into the fault and patterndatabase 4 using a technical support user interface 18 of the patternidentification and distribution module 14.

The APM 28 accesses fault data representative of a fault and using a setof pattern templates defined by the template module 26 it attempts toallocate the fault to a pattern. Patterns are used to cluster faults.The faults which comprise a pattern are believed to have a common cause.The inputted fault can not have previously been allocated to a patternand needs to be cleared for processing first by an analyst using theanalysis centre user interface 16. The pattern templates can be definedby a user of the system 2 using the template module 26, and thetemplates take the following general form:

No. of the same type of fault (>or>=) n over a period of time.

No. of faults of type X (>or>=) n AND . . . over a period of time.

No. of faults of type X (>or>=) n OR . . . over a period of time.

No. of faults of type X PLUS No. of faults of type Y>=10 over a periodof time.

An example of a pattern template is:

No. of faults of type X>=4 OR No. of faults of type Y>4 over the last 60days.

Unallocated faults are grouped together to form a pattern if they matcha pattern template. Once a pattern has been formed, faults which match atype of the template and fall within the period constraints can then beadded to the pattern. A fault is allocated to a pattern if the locationof the fault is covered by the pattern. This is determined by comparingrespective suburb lists associated with the fault and the pattern. Underthe control of the analyst, the APM 28 can be instructed to executegeographic matching not only using a fault's suburb location but alsousing the adjacent suburbs. When a customer's fault is classified asbelonging to a switching network element, matching is not only performedon the suburb, but is also performed using the exchange that serves thesuburb. For example, if fault 1 occurs in suburb A served by exchange Mand fault 2 occurs in a suburb B (not necessarily adjacent to suburb A)but it is also served by exchange M then the two faults would beallocated into the same pattern. The analysis centre user interface 16can provide an analyst with the following information concerning apattern:

(i) The faults that comprise the pattern, and the number of such faults.

(ii) The reason why the pattern is suggested (i.e. which patterntemplate does the pattern satisfy).

(iii) The suburbs that the pattern is likely to cover and theprobability of the pattern appearing in the suburb.

Patterns produced by the APM 28 can be subsequently vetted by thepattern identification and distribution module 14 using the analysiscentre user interface 16. The APM 28 may allocate a fault to two or morepatterns, and then the analyst can choose the most appropriate pattern.The analysis centre user interface 16 can be used to instruct the APM 28to re-evaluate the faults allocation by using wider searches, forexample, extending geographic searching to adjacent suburbs. The APM 28periodically operates in the background to form patterns fromunallocated faults and to re-evaluate to the allocation of faults, whererequested. The APM 28 advises the analysis centre user interface 16 whennew patterns and fault allocations are available for checking.

The APM 28 can be directly activated by an analyst to suggest the set ofpatterns into which a fault can be merged, and can be activatedautomatically periodically, e.g. every hour, as desired, to mergeunallocated faults into existing patterns and/or form new patterns fromthe unallocated faults. New patterns are formed using the templatesdefined by the template module 26, which includes an APM template editordescribed hereinafter. The APM 28 is also activated once every evening,as desired, to determine whether a pattern is stale, i.e. it does notany longer satisfy the template on which it is based. Once a pattern isstale, the APM 28 can no longer merge faults into the pattern. A patternis declared to be stale if over the period of time specified in thepattern's template no additional faults have been allocated to thepattern. An analyst may also have discretion to declare a pattern staleor no longer stale.

When the APM 28 tries to merge a fault into a pattern it considers boththe patterns generated by itself and an analyst. In the case of APMgenerated patterns a merge is successful if the pattern is not stale andits status is not “closed”, the pattern already contains faults of thesame type and at least one suburb in the fault's suburb list appears inthe pattern's suburb list (a geographic match). Merging is identical foranalyst generated patterns but in that case there is no notion of stalepatterns. An analyst entered pattern can be declared to be catastrophic,in which case the pattern takes precedence over non-catastrophicpatterns, and it absorbs all faults that geographically match thepattern (regardless of the types of the faults).

When fault data for a fault is entered in the system 2, the suburbs inwhich it may be present are specified within the fault's suburb list,which is stored in the database 4. The suburb list for a fault isgenerated on the basis of the location data provided with the customeror network fault data. The suburb list for a fault may be enteredmanually by an analyst using the analysis centre user interface 16, orgenerated automatically by the module 14 using a spatial database whichrelates locations reported by customers and network cells and equipmentto specific suburbs. Within each row of the suburb list suburbs are tobe considered joined by a logical AND (&). Each row has an associatedconfidence, a value between 0.0 to 1.0, where 0.0 denotes no confidenceand 1.0 is total confidence that the fault occurred in the suburbs ofthe row. Between rows, AND lists of suburbs are joined by a logicalExclusive-OR (v). The final row of the suburb list is mandatory and itspecifies the confidence for other suburbs, i.e. those not specified inthe list. Tables 1 and 2 are examples of suburb lists for faults f₁ andf₂ where f_(i)rs represents fault i in reported suburbs.

TABLE 1 Suburb List for Fault f₁ Probabilistic Hypothesis Confidence ANDof Suburbs Interpretation h₁f₁ 0.8 A,B P(f₁rs|h₁f₁) = 0.8  h₂f₁ 0.7 CP(f₁rs|h₂f₁) = 0.7  h₃f₁ 0.3 D P(f₁rs|h₃f₁) = 0.3  h₄f₁ 0.01 OtherP(f₁rs|h₄f₁) = 0.01

TABLE 2 Suburb List for Fault f₂ Probabilistic Hypothesis Confidence ANDof Suburbs Interpretation h₁f₂ 0.9 A,B P(f₂rs|h₁f₂) = 0.9  h₂f₂ 0.7 C,FP(f₂rs|h₂f₂) = 0.7  h₃f₂ 0.2 E P(f₂rs|h₃f₂) = 0.2  h₄f₂ 0.01 OtherP(f₂rs|h₄f₂) = 0.01

The logical AND expression appearing in the i-th row of the suburb listof j-th fault is referred to as hypothesis h_(i)f_(j). The confidencevalue associated with the row can be probabilistically interpreted asP(f_(j) in reported suburbs|h_(i)f_(j)).

Associated with each pattern there is also a suburb list. In the case ofa non-catastrophic pattern the suburb list is not entered by an analyst,but it is generated by the APM 28 and it is a merge of the suburb listsof the faults contained in the pattern. The confidence in each row isalso calculated by the APM 28 and the calculations are based on BayesianBelief Networks, as discussed in “Fusion, Propagation and Structuring inBelief Networks” by Judea Pearl, Artificial Intelligence, Vol. 29, p.241-288, with the assumption that the prior beliefs of all thehypotheses are equal. The assumption is valid since the prior beliefsare unknown.

For catastrophic faults the operator must enter one row of the pattern'ssuburb list and the APM 28 assigns it a confidence of 1.0 and other isset to 0.0., reflecting the definite nature of a catastrophic pattern.

The confidence for the rows of the pattern's suburb list are normalised,i.e. the sum of the rows confidence is equal to 1.0. When there is onlyone fault in a pattern, its suburb list is identical to the fault's listexcept that the row confidences are normalised. The fields of a patternstored in the fault and pattern database 4 are as follows:

Field 1: Pattern number

Field 2: Status

Field 3: Creation time and date

Field 4: Pattern description (free format text)

Field 5: Pattern description for CSRs (English jargon free text)

Field 6: Group that currently owns or is responsible for the pattern(customer service, analysis centre, technical support, design)

Field 7: Identity of individual which currently owns or is responsiblefor the pattern

Field 8: List of fault numbers allocated to the pattern

Field 9: Closed time and date

Field 10: Identity of the individual that closed the pattern

Field 11: Reason for closing the pattern

Field 12: Flag indicating whether the pattern is catastrophic

Field 13: List of comments for each group

Field 14: Suburb list

When the APM tries to merge a fault into a pattern, the fault mustgeographically match the pattern, i.e. at least one of the fault'ssuburbs must appear in the patterns suburb list or at least one of thefault's suburbs is adjacent to a suburb in the patterns suburb list.Similarly when the APM creates a new pattern all faults mustgeographically match at least one fault in the pattern. Two faults aresaid to geographically match (a) when there is at least one suburbcommon to both the faults'suburb lists, for example, suburbs A, B and Cappear in both the fault list for f₁ and f₂ or (b) when at least onesuburb of a fault is adjacent to a suburb of the other fault. Note thatwhen an analyst performs a merge of a fault into a pattern therequirement of a geographic match does not need to be satisfied.

The APM 28 determines suburb adjacency by accessing a suburbs'databasemaintained in the database 4 of the system 2. This suburbs'databasecontains for each state, a list of all its suburbs, and for each suburbit contains a list of adjacent suburbs. In this database a country townis equivalent to a suburb.

In order to explain the merging of suburb lists and the calculation ofconfidences for the ensuing list, let us assume that pattern p₁ containsthe fault f₁, and the APM then tries to merge f₂ into it. Before themerge is attempted, the suburb list of p₁ is identical to f₁, per Table3 below, except that the confidences are normalised. The merge ispossible because f₁ and f₂ geographically match. The hypotheses (rows ofthe merged suburb lists) of P₁ are composed of the hypotheses in both f₁and f₂, with duplicates being removed. If one hypothesis is a subset ofanother, for example, h₂f₁ is a subset of h₂f₂, then both hypothesis areincluded in the merged suburb list.

The confidence of a hypothesis is calculated by taking a product of theconfidences of the dependent hypothesis and multiplying it by N, anormalising factor (the sum of the products). The dependent hypothesisof a hypothesis of p₁ containing f₁ and f₂, are hypothesis from f₁ andf₂ that have the same AND of suburbs expression. If for h_(j)p₁, nohypothesis in f_(i) can be found, then the hypothesis corresponding tothe other, and of suburbs expression, is chosen as the dependenthypothesis. For example, in Table 4, the dependent hypothesis for h₂p₁from f₂ is h₄f₂.

TABLE 3 Hypothesis and Confidences for p₁ containing f₁ Dependent AND ofProbabilistic Hypothesis Hypothesis Suburbs Interpretation Confidenceh₁p₁ h₁f₁ A,B N*P(f₁rs|h₁f₁) 0.442 h₂p₁ h₂f₁ C N*P(f₁rs|h₂f₁) 0.387 h₃p₁h₃f₁ D N*P(f₁rs|h₃f₁) 0.166 h₄p₁ h₄f₁ Other N*P(f₁rs|h₄f₁) 0.005

TABLE 4 Hypothesis and Confidences for p₁ containing f₁ and f₂ Hypoth-Dependent AND of Confi- esis Hypothesis Suburbs ProbabilisticInterpretation dence h₁p₁ h₁f₁,h₁f₂ A,B N*P(f₁rs|h₁f₁)*P(f₂rs|h₁f₂)0.9742 h₂p₁ h₂f₁,h₄f₂ C N*P(f₁rs|h₂f₁)*P(f₂rs|h₄f₂) 0.0095 h₃p₁h₄f₁,h₂f₂ C,F N*P(f₁rs|h₄f₁)*P(f₂rs|h₂f₂) 0.0095 h₄p₁ h₃f₁,h₄f₂ DN*P(f₁rs|h₃f₁)*P(f₂rs|h₄f₂) 0.0040 h₅p₁ h₄f₁,h₃f₂ EN*P(f₁rs|h₄f₁)*P(f₂rs|h₃f₂) 0.0027 h₆p₁ h₄f₁,h₄f₂ OtherN*P(f₁rs|h₄f₁)*P(f₂rs|h₄f₂) 0.0001

The APM 28 executes a procedure 40 which begins, as shown in FIG. 2, atstep 41 where a fault f is collected and an attempt is made to merge thefault f into a pattern. At step 42, an attempt is made to add the faultf to all catastrophic patterns which are not stale, not closed and whichalso geographically match the fault. Next at step 44, a check is made todetermine whether the fault has been added to any catastrophic pattern,and if so the procedure 40 breaks to step 50. If the fault has not beenadded to a catastrophic pattern, at step 46 an attempt is made to addthe fault to patterns which have been generated by the APM 28 and whichare not stale, not closed, geographically match f and include faults ofthe same type as f. Faults are considered to be of the same type if theyhave the same symptom codes and are of the same fault class. Next atstep 48, an attempt is made to add f to all faults which have beengenerated by an analyst and which are not closed, geographically match fand contain faults of the same type as f. At step 50 a determination ismade as to whether the APM 28 has been activated by an analyst, and ifso the procedure 40 ends at step 52, otherwise the APM moves to step 51.The APM 28 at step 51 seeks to create new patterns using the patterntemplates and any faults in the fault and pattern database 4 which havenot been allocated to a pattern.

The APM editor of the template module 26 is used to create templates.Templates are used by the APM 28 to form patterns from faults that arenot already allocated to a pattern. All faults that match a template aregrouped into a pattern, as mentioned previously.

A template file can contain multiple templates of the following types,with exception that it can contain only one template of the type SAME:

(i) SAME TEMPLATE [No. of faults of the same type (>or>=) n] over thelast d days.

(ii) OR TEMPLATE [No. of faults of type X (>or>=) n] v [No. of faults oftype Y (>or>=) m] v . . . over the last d days.

(iii) AND TEMPLATE [No. of faults of type X (>or>=) n] & [No. of faultsof type Y (>or>=) m] & . . . over the last d days.

(iv) SUM TEMPLATE [No. of faults of type X]+[No. of faults of type Y] +. . . [(>or>=) n] over the last d days.

For the OR, AND and SUM types of templates, fault types need to bespecified. A fault type is specified by selecting the fault's class andcode on add and edit condition windows. Four classes of faults include:

(a) Analogue Network Customer Reported Faults

(b) Digital Network (GSM) Customer Reported Faults

(c) Network Reported Cell Faults

(d) Network Reported Exchange Faults

The pattern identification and distribution module 14 allows mobilenetwork analysts to form fault patterns and distribute them forprocessing amongst appropriate groups. The system 2 has an upper limiton the number of groups, and each group, although being able to forwarda pattern to any other group, may be restricted by allowed referralsdefined for each region. The module 14 includes one analysis centre userinterface 16, one technical support user interface 18, one supervisoruser interface 22 and a number of design user interfaces 20 for regiongroups. The design user interface 20 essentially allows a group memberto view all of the patterns forwarded to the group, add a remark to thepattern, and forward a pattern to another group.

Two forms of pattern distribution are provided, the first form being atransferring of responsibility or ownership for a pattern to anothergroup and in the second form responsibility or ownership remains withthe initial group but an action to be performed on the pattern can beforwarded to another group. Each member of the design group has on theirinterface 20 an indicator of the number of faults that have beenallocated to the group, but are not yet allocated to a group member.

The analysis centre user interface 16 allows a mobile network analyst toperform the following tasks:

(i) Extract customer fault data from the customer fault databases 6 whenprompted by the interface 8 on their availability.

(ii) Determine whether the extracted fault should be processed by thesystem 2. This process can be considered as executing a fault gate. Ifthe fault is not to be processed by the system 2, it is placed in adifferent queue of the customer fault databases 6. Once the fault isaccepted for processing a suburb list is appended to the fault, whichmay be done by an analyst. If the fault is not placed in the system 2for processing, the reasons for returning it to the customer faultdatabases 6 are placed in a clearance comments fields of the customerfault data.

(iii) View all faults and patterns held in the fault and patterndatabase 4 so that faults can be manually merged into existing and newpatterns. When an analyst manually forms a pattern, rules used informing the pattern can be added to the record of the pattern.

(iv) Invoke the APM 28 to produce suggested patterns. The suggestedpatterns can then be checked for acceptability, by executing a processreferred to as a pattern gate before the patterns are further processed.On passing a pattern via the gate, the analyst can allocate a priorityfor processing of the pattern.

(v) If the fault is hard-on fault, the analyst can transfer a patternincluding the fault to a responsible group. A hard-on fault is a faultwhich is obvious, and not subtle, i.e. the link between a base stationand exchange is down.

(vi) If the fault is subtle, the analyst can add comments and pass thepattern including the fault to the technical support user interface 18for further processing.

(vii) When a pattern returns from a design group with an action plan,the analyst can translate the action plan into a plain Englishdescription which can then be presented to the CSRs. The elements of thepattern viewable by the CSRs is controlled using the analysis centreuser interface 16, which prompts the analyst on the arrival of patternsfrom the design group.

(viii) When a pattern returns from a design group with a status of beingfixed, the analyst can automatically add clearance comments into thecustomer fault databases 6 for each fault in the pattern. Clearancecomments can also be added to hard-on faults and other faults notbelonging to a pattern. When a clearance comment is added to a fault,the fault is placed in a feedback queue in the customer fault databases6.

(ix) Archive fixed patterns.

(x) Delete fixed faults and patterns from the fault and pattern database4.

The analysis centre user interface 16 also enables the entry of faultsdetected by test surveys into the database 4. Test survey faults can bemerged into patterns manually or sing the APM 28 if such faults includelocation information from which a suburb list can be derived.

When part of the network becomes completely disabled or a network outageoccurs, the interface 16 allows an analyst to add a catastrophic patterninto the fault and pattern database 4 either manually or using the APM28. Depending on the severity of the fault, a message can also bebroadcast to the customer service module 30. The analyst enters thesuburbs the outage impacts, and once the pattern is entered, all faultsreported in the impacted suburbs, regardless of times, are allocated tothe catastrophic pattern.

All patterns are allocated a status which affects whether a pattern canbe viewed by he CSRs using the customer service module 30, as follows:

(i) APM suggested. The APM 28 has suggested the pattern. Not viewable byCSRs.

(ii) Analyst suggested. An analyst has suggested the pattern. Notviewable by CSRs.

(iii) Accepted. The analyst has accepted a suggested pattern, but noaction plan has been created. Not viewable by CSRs.

(iv) Planned. A design group has created an action plan. The pattern isonly available to a CSR if a fault that he/she queries belongs to thepattern.

(v) Inactivated. The pattern exists but the current action plan is “noaction”. More faults can be added to the pattern. CSR viewable undercontrol of analysis centre user interface 16.

(vi) Considered. The action plan has been considered by a group and itsoutcomes are sent to the CSRs for customer follow-up. Every change ofresponsibility or group, or action by a group raises an “activity” oradvice to the CSRs if a network analyst believes it's relevant.

(vii) Closed. The problem indicated by the pattern is fixed. Underanalysis centre user interface control advice is sent to the CSRs whenthe pattern is closed. A closed pattern remains available to theinterfaces 16, 18, 20 and 22 for a specific period of time. After thattime expires the pattern is archived. Once the pattern is archived it isno longer viewable by CSRs.

Only statuses (i), (ii) and (vii) are mandatory, and the others may bespecified on a regional basis. Each group may set up non-mandatorystatuses, as desired, for the patterns they process.

Hereinafter reference is made to specific screen interfaces and thebuttons which may be used on those interfaces. It will be understoodthat whilst the function of the interfaces may not vary, the particularconfiguration and buttons used on the screens may vary considerably.

The APM template editor is activated by clicking on an APM TemplateEditor button on a top window of the analysis centre user interface 16.

The editor is used to create a New file, or Edit or Delete a file oftemplates. The templates in the active template file are used by the APM28 to form new patterns. A file is made active by selecting it and thenclicking on the Set Active Template File button.

A new template file is created by entering a filename in a File fieldand pressing a New button. A template file is edited by selecting thefile in a scrolling list and then clicking on an Edit button. When anEdit or New button is selected a window is displayed which contains asummary of the templates appearing in the file. At this stage a newtemplate can be added by selecting the Add Template button or anexisting template can be modified by selecting its entry in the summarylist and then clicking on Edit Template. Clicking on either of thesebuttons pops up a window containing a detailed description of thetemplate. On this window a template's details can be added or modified,including its type, whether geographic matching is performed whenassigning faults to a pattern that is based on the template, the numberof previous days over which fault counts are taken, and the faultconditions. Conditions (items appearing in square brackets in thefollowing description of template types) can be added, edited anddeleted from a template by selecting the Add Condition, Edit Conditionand Delete Condition buttons.

By pressing a Get Faults button of the analysis centre user interface 16the user is presented with a screen which is used to extract customerfault data from a queue of the customer fault databases 6. The usershould select whether the next fault to be examined for possible entryin to the network fault system 2 is of type analogue or digital. Anexclusive type selection box is provided at the top of the screen forthis purpose. Activating a Get Next button places a summary of the faultin to a scrolling list and it is “actioned” in the customer faultdatabases 6. By clicking on the summary line in the scrolling list, ascreen displaying all fault information is displayed.

In the fault display, some fields will already be filled in. Thesefields are non-editable and contain information obtained from thecustomer fault databases 6.

Selection of a Cancel button will close the fault display. The samefault can be viewed again later. The fault will not be entered into thenetwork fault system 2 should Cancel be chosen.

Towards the bottom of the screen, one of three choices is required:

(i) Hard-on. The fault is a hard—on fault. The fault is saved in thenetwork fault system 2 and a facsimile can be printed.

(ii) Further Analysis. The fault is suitable for entry in to the networkfault system 2 without further processing at this stage.

(iii) Refer On. The fault is probably not suitable for entry into thenetwork fault system 2. A screen will be displayed where certain actionis required. A tick box is used to select whether or not the faultshould be entered into the network fault system 2. By selecting Commentand Queue fields are sent to the customer fault databases 6, updatingthe clearance comments and dispatch code fields respectively of thecustomer fault databases 6 fault record. An OK button will activate therefer on.

By selection of Hard-On, Further Analysis or Refer On followed by theContinue button, the appropriate action is taken. A fault number will beallocated by the network fault system 2 whenever a fault is entered.Continue will remove the fault summary from the scrolling list.

A test drive fault entry procedure of the interface 16 allows entry ofspecial fault information. Such information could be obtained from faultsurveys, field testing, etc. A Continue button will allow entry of thefault in to the network fault system 2. A fault number will be allocatedby the network fault system 2. Geographic information regarding testdrive faults is specified identically as for faults sourced from thecustomer fault databases 6.

By selecting Pattern Entry an empty pattern (no faults) can be created.A consultant view tick box can be used to make the corresponding patterndescription viewable to CSRs via the customer service module 30. At thetime of entering faults into the network fault system 2, an Add To Newmay be selected. This will create a pattern with one fault merged in toit, that fault being the one currently under view.

A Comments button will bring up a screen which is used to enterinformation regarding progress of action upon the pattern. Each group isassigned a box where comments may be entered. An additional box isprovided where a description of the planned action for the pattern canbe entered. The description in this box is specifically for the customerservice module (CSM) 30.

When an action plan has been formulated, date fields: action plancreation date; and action plan completion date, are used. In the presentsystem 2, the comments screen is open to modification by any person.

There are four main groups: CSR, mobile network analysis centre (MNAC),technical support and design. A pattern has an associated ownership ofboth its action and responsibility. The ownership will be with one ofthe members of a group. When a pattern is created, both theresponsibility and action for the pattern will belong to the creatinggroup, MNAC. The ownership of either action or responsibility can bechanged to another group provided the current owner initiates thehandover. Patterns are transported to a group for subsequent grabbing,where a newly transported pattern is assigned to a member of the group.A pattern of no faults may be selected for transport to another groupusing Transport Action and Transport Responsibility buttons. Pressing aContinue button will enter the newly created pattern in to the networkfault system 2. The comment and transport information is saved at thetime of selecting Continue.

Pattern searching enables a user to retrieve patterns from the networkfault system 2, update pattern information, merge faults in to thesearched for pattern and clear patterns. Clicking a Pattern Searchbutton will bring up a screen where search criteria can be entered. Thisis essentially a formulation of a request that the network fault system2 list all those patterns that comply with the search criteria. In eachfield, data can be entered in three ways:

(a) Absolute value, e.g. Pattern Number—32.

(b) Group of values, e.g. Suburb-Parramatta, Mosse Vale, Chatswood.

(c) Wild card, e.g. Pattern Number—3% (This would match all patternswhere the first digit of the pattern number was 3). The “%” matches anystring of zero or more characters except null.

The search is executed using a Search button. The result of the searchoperation is presented in a large screen where each row is a summary ofa pattern that matched the search criteria. Arrow buttons that appear onthe screen are used to scroll through the list of patterns that werefound.

Once a search has been executed one of the patterns found to match thesearch criteria can be examined and updated. This is done by using tickboxes at the left of the screen brought up after a pattern search isexecuted. A Detail button will expand information on the pattern whichhas had its tick box selected.

The pattern information can be changed at this point. Transfers andupdates to comments can also be made. The changes are stored in thenetwork fault system 2 when the Update button is chosen.

Clearing of patterns involves clearing all of the faults that comprisethe pattern. This process will communicate with the customer faultdatabases 6 updating Dispatch Code and Clearance Comments fields of thefault on the customer fault databases 6. The information sent to thecustomer fault databases 6 as part of the clear procedure is enteredinto the screen brought up by the Clear Pattern button. The DispatchCode will be set to “FBCK” and the Clearance Comments field will be setto Cause Code, Clearance Code and Comment fields of the current screen.

Merging faults into patterns involves associating a given list of faultswith a given pattern, as described previously. Fault Search can bechosen after a pattern search is executed. The fault search will requireentry of search criteria in a similar fashion to searching for apattern. The fault search operation also presents the result of thesearch in a large screen similar to that for patterns. An Add Faults toPattern button merges the tick box selected faults into the tick boxselected pattern. If faults chosen for the merge already belong toanother pattern, such faults will be removed from the other patternbefore the merge takes place. Following a merge the suburb list of thepattern is updated to reflect the merge. At the time of enteringcustomer faults in to the network fault system 2, a Pattern Search mayalso be executed. In this case, the fault merged into the patternselected will be that fault currently under view.

Fault search enables a user to retrieved faults from the network faultsystem 2, update fault information, merge faults into a pattern andclear faults. The Fault Search button allows entry of fault searchcriteria, as described above. Faults can be examined and updated by useof tick boxes displayed after search execution. Operations of Detail,Update and Clear buttons is similar to that for patterns.

A group of faults can be selected for a merge operation by using thetick boxes of the search result screen to select faults. The PatternSearch button, followed by Add Faults to Pattern will merge the tickboxed faults into the tick boxed pattern.

A View Own Patterns button provides a special form of pattern searching.The network fault system 2 is queried for those patterns for which theownership of either the responsibility or action or both, is with thepresent user of the system. Patterns may only be updated and transportedat this stage with the added proviso that transport can only take placeif the pattern is owned by the present user of the system. Using a ViewNew Action Patterns button, the network fault system 2 is queried forthose patterns that have had action transported to the group of thepresent user of the system. Using a View New Responsibility Patternsbutton, the network fault system 2 is queried for those patterns thathave had responsibility transported to the group of the present user ofthe system. Grab and Continue buttons will assign the ownership of theresponsibility for the pattern to the present user of the system.

The customer service module 30 provides a CSR with access to the networkfault system 2 and runs under Microsoft Windows™ on a PC. The connectionbetween the PC and the Unix machine of the network fault system 2 can beachieved using a communications package such as Oracle Glue™. Theconsultant user interface 32 enables the CSR to carry out enquiries onthe pattern information held in the fault and pattern database 4 for thepurposes of informing customers of a pattern which may be causing theirparticular fault. The interface 32 allows a CSR to list the set ofpatterns in a suburb.

The CSR types in the suburb name, and its spelling is checked. If thesuburb is valid a list of patterns appearing in that suburb isdisplayed. For each pattern in the list, its identification number,description and impact area is displayed. The impact area is a landmarkwithin the suburb, e.g. road, intersection, shopping centre, etc. TheCSR can expand a pattern, and in the expanded version, in addition tothe impact area, the description contains a plain English explanation ofthe pattern, an action plan as well as a number of other less criticalfields.

For patterns that are suggested by the APM 28, the impact area ismanually entered by a MNAC analyst as the APM 28 does matching on asuburb level. If an outage covers the suburb queried, the outage patternappears at the top of the list of patterns impacting the area.

Patterns with a particular identification number can also be retrieved.

The customer support user interface 34 enables a CSR to carry out thereporting of pattern information to customers whose faults have made upthat pattern and the subsequent transfer of the pattern information backto the MNAC. The interface can be used to list all of the patternstransferred to the customer support group not allocated to any CSR.

The patterns are presented in a list, and each pattern entry in the listcontains the date it was created, its description and impact area. TheCSR can expand a pattern entry in the list. The expanded patterncontains a description of pattern (understandable by the CSR). On theexpanded pattern the CSR has the ability to allocate responsibility forhandling the pattern to himself/herself, view the customer faultsbelonging to the pattern, and can transfer the pattern back to MNAC andthe analysis control user interface 16.

A list of all the patterns transferred to the customer support group andallocated to a specific CSR can also be obtained.

A CSR activates the customer service module 30 by clicking on a networkfault system icon. Next the operator is prompted to enter his/herinitials (3 characters) and a password, but the entered values are notverified. The operator's initials are used to tag patterns as belongingto the operator (for grabbing patterns) and the password is used toaccess the fault and pattern database 4 in the network fault system 2. Awindow then appears in which a button needs to be pressed to gainconnection to the network fault system 2.

All patterns that have not been “closed” and that are viewable by CSRscan be viewed by entering the suburb into a For Suburb field and hittingreturn. This brings up a list of all the patterns in the suburb. Bydouble clicking on an entry full details of the selected pattern aredisplayed.

MNACs can transfer patterns to the CSR group for processing, asdescribed previously. By clicking on a New button a list of suchpatterns that have not yet been grabbed by a CSR is displayed. By doubleclicking on an entry in that list a detailed description of the patternappears. Clicking on a check box Grab Pattern, assigns ownership of thepattern to the CSR identified by the initials which were entered onstarting up the customer service module 30.

Clicking on an Own button displays the list of patterns grabbed by theCSR. Double clicking on an entry in the list brings up a windowcontaining a detailed description of the pattern. The pattern detailwindow contains a scrolling list of faults belonging to the pattern.Double clicking on an entry in that list brings up a detaileddescription of the fault, which includes customer contact details. Oncethe CSR is finished processing the pattern it can be returned to theMNAC group by clicking on a check box Transfer Pattern to MNAC.

The technical support user interface 18 enables a technical supportconsultant (TSC) to perform the following tasks:

(a) Retrieve patterns forwarded to the technical support group from MNACor a design group. Alternatively, a consultant may choose to be promptedon the arrival of such patterns.

(b) Add the technical support group comments to a pattern, beforeforwarding to a design group or MNAC.

(c) Forward confirmed patterns (received from MNAC) to a design groupfor processing.

(d) Forward patterns that the TSC could not confirm to MNAC.

(e) View all the patterns in the fault and pattern database 4.

(f) Enter network faults from the network analysis system 10.

The technical support user interface 18 provides Pattern Search, Searchand Detail buttons which allow execution of the same pattern searchingprocedures as for the analysis centre user interface 16. A Commentsbutton also brings up a screen which can be used to enter informationregarding progress of action on the pattern in a box for the group.Transport Action, Transport Responsibility and Update buttons alsoperform the same functions as for the analysis centre user interface 16.

Faults can be searched using procedures executed by clicking on a FaultSearch button, and patterns viewed using view using view own patterns,Grab and Continue buttons as for the analysis centre user interface 16.The interface 18 also provides access to the network data entry userinterface 12, which allows the TSC to enter into the fault and patterndatabase 4 faults which have been detected by the network analysissystem 10 and are believed to have an affect on customers. When anetwork fault is entered into the database 4, the TSC enters adescription of the network fault, and a set of one or more suburbs whichthe fault affects. Alternatively, as discussed previously, a spatialdata system which maps network cells and exchanges to suburbs can beinvoked to enter automatically the set of suburbs.

An entered network fault can be considered as a pattern with whichcustomer faults can be merged, and the merger may be performed eithermanually using the analysis centre user interface 16 or automaticallyusing the APM 28, as described previously.

The design user interface 20 is the same as the technical support userinterface 18 and allows a design consultant (DC) to perform thefollowing tasks:

(a) Retrieve patterns forwarded to a design group from the technicalsupport group. Alternatively, a consultant may choose to be prompted onthe arrival of such patterns.

(b) Add an action plan to a pattern, and to manage the status of theplan.

(c) Forward patterns for processing to the technical support group ordirectly to MNAC.

(d) View all the patterns in the fault and pattern database 4.

The design group plans and then coordinates the solution of a faultamongst a number of groups which may not have access to the networkfault system 2. Under such circumstances the interface 20 enables the DCto record the interactions of the design group with these groups. Inaddition, the design group may instruct a number of its staff to performa series of tests in order to formulate an appropriate action plan. Theinterface 20 will enable the recording of the nature of test to beperformed, the identity of the staff that perform the tests and theresults of the tests.

The supervisor user interface 22 allows a supervisor for the patternidentification and distribution module 14 to perform a number ofsupervisory tasks on the module 14, which include process performancespecification and report production.

In a process performance specification a supervisor can specify theamount of time that an element of the pattern distribution process cantake. For example, technical support must forward a pattern either backto MNAC or to a design group within four hours of receiving it fromMNAC, and a design group must forward a pattern back to MNAC within aweek from when it was received from technical support.

The reports that can be produced by the interface 22 include:

(a) List of known patterns sorted geographically.

(b) Status of a pattern, including the group working on it and how longit will take to solve.

(c) List of each area giving turn around times, outstanding patterns,clearance times and times for each stage of the pattern distributionprocess.

(d) Status of the fault and pattern database 4, which includes thenumber of cleared and uncleared faults per month.

(e) List of patterns for which the process performance specificationswere not met.

(f) An audit trail for a pattern, such as who did what and when.

Each group has access to statistics regarding its own performance.

What is claimed is:
 1. A network fault system for a mobiletelecommunications network including: a first interface for accessingfirst fault data representative of faults reported by users of mobilestations of said network; a second interface for accessing second faultdata representative of faults in said network determined by a networkanalysis system; and pattern matching means for allocating said firstand second fault data to fault patterns representative of faults havingat least one common characteristic.
 2. A network fault system as claimedin claim 1, wherein the common characteristic is geographic location. 3.A network fault system as claimed in claim 2, wherein a further commoncharacteristic is fault type.
 4. A network fault system as claimed inclaim 1, including pattern generation means for generating said faultpatterns using respective fault templates to allocate said fault data tosaid fault patterns.
 5. A network fault system as claimed in claim 4,wherein said fault templates represent a predetermined condition havingoccurred over a predetermined period of time, said condition comprisinga predetermined number of faults of a predetermined type havingoccurred.
 6. A network fault system as claimed in claim 5, wherein saidfault templates represent a logical relationship between at least two ofsaid predetermined condition having occurred over a predetermined periodof time.
 7. A network fault system as claimed in claim 4, wherein saidfault templates represent a predetermined number of faults of differentpredetermined types having occurred.
 8. A network fault system asclaimed in claim 1 or 4, wherein said fault patterns each includegeographic data representing at least one geographic location associatedwith respective faults, said fault data each include location datarepresentative of at least one geographic location associated with thefault represented by said fault data, and said pattern matching meansallocates said fault data to one of said patterns when the location dataof the fault data corresponds to the geographic data of the pattern. 9.A network fault system as claimed in claim 8, wherein to allocate thefault data to said pattern, the pattern further includes faults of thesame type as the fault represented by said fault data.
 10. A networkfault system as claimed in claim 4, wherein said pattern generationmeans generates new fault patterns by applying said templates to saidfault data not allocated to existing fault patterns.
 11. A network faultsystem as claimed in claim 1, including a customer service system forproviding access to said patterns when processing said faults reportedby users, and for generating and storing said first fault data.
 12. Anetwork fault system as claimed in claim 1 or 11, including adistribution module allowing access, editing and transmission of saidpatterns by parties having different tasks in relation to processing ofsaid patterns.
 13. A network fault system as claimed in claim 12,wherein said patterns have respective statuses, and the status of apattern is changed to closed by one of said parties when a networkproblem associated with the faults of the pattern is fixed.
 14. Anetwork fault system as claimed in claim 8, wherein said location dataincludes: locations and location confidence values representing theprobability of the fault of said fault data having occurred at at leastone of the locations and another confidence value representing theprobability of the fault not having occurred in said locations; and saidgeographic data includes locations and location confidence valuesrepresenting the probability of the faults of said pattern havingoccurred at at least one of said locations and another confidence valuerepresenting the probability of the faults not having occurred in saidlocations, said confidence values of said pattern being normalised. 15.A network fault system as claimed in claim 14, wherein said locationdata corresponds to said fault data when at least one of the locationsof said location data is the same as one of the locations of saidgeographic data.
 16. A network fault system as claimed in claim 15,wherein on allocating said fault data to said pattern, said confidencevalues of said pattern are the product of said location confidencevalues of said fault and said another confidence value of said pattern,the product of said location confidence values of said pattern and saidanother confidence value of said fault data and, for location confidencevalues of said fault data and said pattern having the same respectivelocations, the product of these location confidence values.
 17. A faultpattern matching process including: accessing first fault datarepresentative of faults reported by users of mobile stations of amobile telecommunications network; accessing second fault datarepresentative of faults in said network determined by a networkanalysis system; and matching said first and second fault data to faultpatterns representative of faults having at least one commoncharacteristic.
 18. A fault pattern matching process as claimed in claim17, wherein the common characteristic is geographic location.
 19. Afault pattern matching process as claimed in claim 18, wherein a furthercommon characteristic is fault type.
 20. A fault pattern matchingprocess as claimed in claim 17, including generating said fault patternsusing respective fault templates to allocate said fault data to saidfault patterns.
 21. A fault pattern matching process as claimed in claim20, wherein said fault templates represent a predetermined conditionhaving occurred over a predetermined period of time, said conditioncomprising a predetermined number of faults of a predetermined typehaving occurred.
 22. A fault pattern matching process as claimed inclaim 21, wherein said fault templates represent a logical relationshipbetween at least two of said predetermined condition having occurredover a predetermined period of time.
 23. A fault pattern matchingprocess as claimed in claim 20, wherein said fault templates represent apredetermined number of faults of different predetermined types havingoccurred.
 24. A fault pattern matching process as claimed in claim 17 or20, wherein said fault patterns each include geographic datarepresenting at least one geographic location associated with respectivefaults, said fault data each include location data representative of atleast one geographic location associated with the fault represented bysaid fault data, and matching said fault data to one of said patternsoccurs when the location data of the fault data corresponds to thegeographic data of the pattern.
 25. A fault pattern matching process asclaimed in claim 24, wherein matching the fault data to said pattern,the pattern further includes faults of the same type as the faultrepresented by said fault data.
 26. A fault pattern matching process asclaimed in claim 20, including generating new fault patterns by applyingsaid templates to said fault data not allocated to existing faultpatterns.
 27. A fault pattern matching process as claimed in claim 17,including providing access to said patterns when processing said faultsreported by users, and generating and storing said first fault data. 28.A fault pattern matching process as claimed in claim 17 or 27, includingenabling access, editing and transmission of said patterns by partieshaving different tasks in relation to processing of said patterns.
 29. Afault pattern matching process as claimed in claim 28, wherein saidpatterns have respective statuses, and including one of said partieschanging the status of a pattern to closed when a network problemassociated with the faults of the pattern is fixed.
 30. A fault patternmatching process as claimed in claim 24, wherein said location dataincludes: locations and location confidence values representing theprobability of the fault of said fault data having occurred at at leastone of the locations and another confidence value representing theprobability of the fault not having occurred in said locations; and saidgeographic data includes locations and location confidence valuesrepresenting the probability of the faults of said pattern havingoccurred at at least one of said locations and another confidence valuerepresenting the probability of the faults not having occurred in saidlocations, said confidence values of said pattern being normalised. 31.A fault pattern matching process as claimed in claim 30, wherein saidlocation data corresponds to said fault data when at least one of thelocations of said location data is the same as one of the locations ofsaid geographic data.
 32. A fault pattern matching process as claimed inclaim 31, wherein said matching of said fault data to said patternincludes setting said confidence values of said pattern to the productof said location confidence values of said fault and said anotherconfidence value of said pattern, the product of said locationconfidence values of said pattern and said another confidence value ofsaid fault data and, for location confidence values of said fault dataand said pattern having the same respective locations, the product ofthese location confidence values.